# Chapter 8: Multicasts

Multicasting is an alternative to unicasting that reduces the number of broadcast streams in use. Although it can increase the audience for a live event by reducing the broadcasting bandwidth, it requires a specially configured network, and is more suited for intranets than Internet delivery. You can multicast RealMedia, QuickTime, Windows Media, MPEG, and a number of RTP-based formats.

# Understanding Multicasts

As Chapter 7 explained, unicasting delivers a unique broadcast stream to each media player. In contrast, multicasting sends a single live stream to multiple players. The multicast can be a live event, or a prerecorded clip broadcast by SLTA, which Chapter 10 explains. The players connect to the stream, rather than to the Helix Universal Server, as shown in the following illustration.

##### Multicasting

## Back-Channel Multicasting

Back-channel multicasting works with all RealNetworks media players, including older players that use only the PNA protocol. In this method of multicasting, each media player maintains a control channel to Helix Universal Server. A media player uses its channel to send commands such as Stop, and to deliver statistics about the quality of service to the archive log. The channel lets Helix Universal Server receive a user name and password if authentication is used. It also enables the Server Monitor described in Chapter 18 to track how many players are viewing the multicast.

##### Back-Channel Multicasting

| Note: Because each player uses a control channel, back-channel multicasting is limited to the number of client connections licensed to your Helix Universal Server.

### Unicast Failovers

If a RealNetworks media player is not multicast-enabled, or cannot connect to the back-channel multicast, it fails over to a unicast automatically. This ensures that all players can receive the broadcast. Because each unicast stream consumes extra bandwidth and Helix Universal Server overhead, you can choose to disable the failover feature and provide just the multicast. In this case, a player not able to participate in a multicast receives an error message when attempting to connect to the broadcast.

| Tip: You can use back-channel multicasting with the failover feature for all broadcasts to RealNetworks media players. By default, players attempt a back-channel multicast connection first, switching to unicast if the failover feature is enabled, and the multicast is not available. Hence, enabling an automatic multicast for all broadcasts can help conserve bandwidth.

## Scalable Multicasting

Using a scalable multicast, you can broadcast to an unlimited number of media players because the transmission is one-way. Unlike back-channel multicasting, scalable multicasting does not use a control channel. Thus, it uses less bandwidth, administrative overhead, and system resources on Helix Universal Server. Scalable multicasting works with RealPlayer G2 and later. You can also multicast to any RTP-based media player that complies with scalable multicasting standards, including Apple's QuickTime Player.

##### Scalable Multicasting

### Session Description Files

Viewers connect to scalable multicasts by clicking a link to a Session Description Protocol (SDP) file, which Helix Universal Server automatically generates. All data is multicast on the network once, and media players do not connect to Helix Universal Server during the multicast. Because of this, tools such as Server Monitor do not track client connections and activity during the broadcast.

### Authentication and Statistics

Because media players do not connect to Helix Universal Server directly during the multicast, you cannot enforce user name and password validation in a scalable multicast. Optionally, you can have players connect to Helix Universal Server or a Web server to deliver quality of service statistics when the broadcast ends (or they disconnect).

### Unicast Failovers

Like back-channel multicasting, scalable multicasting has a failover feature that lets you direct RealNetworks media players to a unicast if they cannot receive the multicast. You can provide a unicast on the same Helix Universal Server that hosts the multicast, or choose a different Helix Universal Server. As well, you can direct players to a Web page that indicates that the multicast is not available, and provides information about broadcast alternatives.

## Windows Media Multicasts

Helix Universal Server can deliver scalable multicasts in the Windows Media format to Windows Media Players. Each multicast is pulled from Windows Media Encoder, and made available to players on a single multicast channel. Players click a Web page link to an NSC file to join the multicast. You can designate a unicast URL for players that cannot join the multicast. Unlike with RealMedia back-channel multicasts, Helix Universal Server cannot make all Windows Media unicasts automatically available as multicasts. As well, archiving of Windows Media multicasts is not supported.

## Network Configuration for Multicasts

To use multicasting, Helix Universal Server, media players, routers, switches, and all other networking devices between them must be multicast-enabled. For this reason, multicasting is primary used on intranets. However, it is possible to deliver multicasts over the Internet where intermediary network devices have been multicast-enabled. Before using multicasting, verify the following with your network administrator:

- Routers and all equipment in your network are multicast-enabled.

- The machine running Helix Universal Server is correctly configured for multicast support.

| Tip: RealNetworks and Microsoft media players are configured for multicast by default, although viewers can turn off multicast support in their player preferences.

### Multicast Addresses

A multicast requires the use of a continuous range of multicast addresses on your network. Valid ranges are between `224.0.0.0` and `239.255.255.255`. Check with your network administrator about which multicast addresses are available on your network. On the public Internet, certain ranges in the multicast address space (from `224.0.0.0` to `224.0.0.255`) are reserved, and cannot be used.

The number of addresses required for a multicast depends on the type of multicast you use, as well as the number of streams you deliver. For scalable multicasting, you also need to reserve a number of Helix Universal Server ports for the broadcast. The sections on setting up each type of multicast explain the number of addresses and ports you need.

| Warning! If you use multiple types of multicasts, such as both back-channel and scalable multicasts, the address ranges you pick cannot overlap.

### Packet Time to Live

All multicast broadcasts include a "time to live" feature. As a multicast data packet passes through a multicast-enabled router, its time to live decreases by 1. When the value reaches 0, the router discards the data packet. When you set up a multicast, you specify a time to live of `0` to `255`. The larger the value, the greater the distance a packet can travel. The default value of `16` typically keeps multicast packets within an internal network. The following table summarizes possible values.

Time to Live (TTL) Values
TTL Value | Packet Range
--- | ---
`0` | local host
`1` | local network (subnet)
`16` | intranet
`32` | site
`64` | region
`128` | continent
`255` | world

### Multicasts with Multiple Network Interface Cards

If your Helix Universal Server machine has multiple network interface cards (NICs), and you want to ensure that Helix Universal Server always uses a particular NIC for multicasts, use your operating system to set a default address. On Windows, set IP bindings as described in "Binding to an IP Address". On UNIX, use the route command to associate the multicast route with the appropriate NIC.

## Multicasting Used with Other Features

The following sections summarize how multicasting works with other Helix Universal Server features.

#### Splitting and Multicasting

Transmitters can multicast a stream to receivers, as explained in Chapter 9. This does not require the setup described in this chapter, which concerns only server-to-player multicasts. If the receiver multicasts a stream to media players, however, you must configure the receiver for multicasting as described in this chapter.

#### Live Archiving and Multicasting

As with all live broadcasts, you can configure Helix Universal Server to archive files for live multicasts in the RealMedia or MP3 format. Helix Universal Server does not archive MPEG-4 or Windows Media multicasts.

#### Simulated Live Broadcasts with Multicasting

You can multicast a simulated live stream from on-demand clips using SLTA, which Chapter 10 describes.

#### Helix Universal Proxy and Multicasting

Depending on how the network is configured and the streams are listed in Helix Universal Server, clients whose requests are forwarded by a Helix Universal Proxy may receive different results.

Helix Universal Proxy cannot join a multicast. Instead, it will try to receive the multicast using pull splitting. If pull splitting is enabled on the source Helix Universal Server, Helix Universal Proxy will use that broadcast, instead of connecting to the multicast. The client will receive the broadcast in unicast mode.

If there is a multicast-enabled network between Helix Universal Proxy and the client, Helix Universal Proxy can be configured to re-send its pull split stream by multicast instead.

| For More Information: Refer to Helix Universal Proxy Administration Guide for information on configuring Helix Universal Proxy.

#### Firewalls and Multicasting

Multicasts usually take place within an intranet, where broadcasts are not traveling outside a firewall. If a multicast passes through a firewall, the firewall must be specially configured to allow multicast traffic.

#### Access Control, Authentication, and Multicasting

As with all delivery methods, Helix Universal Server verifies that the client requesting a broadcast is allowed to receive it. If you include the authentication mount point (`/secure/`) in the link, Helix Universal Server verifies the viewer's identity. You cannot authenticate scalable multicasts, however.

#### Reporting and Multicasting

Streams served through back-channel multicasts appear in the access log just like unicast material. The access log shows which method was used to transmit the stream. Scalable multicasts can be identified in the access log by their mount point in the `GET` statement. If Helix Universal Server is configured for requesting client statistics (see "Gathering Client Statistics"), the log file will also contain statistics for each client.

## Multicast Resources

The Helix Universal Server implementation of back-channel and scalable multicasting is based on open industry standards. You may find the following resources useful.

### General Multicasting Information

- Addresses available for multicast use—"Assigned Numbers," RFC 1700, available at http://www.ietf.org/rfc/rfc1700.txt.

### Scalable Multicasting Information

- RTP— "RTP: A Transport Protocol for Real-Time Applications," RFC 1889, available at http://www.ietf.org/rfc/rfc1889.txt.

- RTP—"RTP Profile for Audio and Video Conferences with Minimal Control," RFC 1890, available at http://www.ietf.org/rfc/rfc1890.txt.

- SDP (Session Description Protocol)—"SDP: Session Description Protocol," RFC 2327, available at http://www.ietf.org/rfc/rfc2327.txt.

- SAP (Session Announcement Protocol)—"Session Announcement Protocol: Version 2," available at http://www.ietf.org/rfc/rfc2974.txt.

# Defining Back-Channel Multicasting

Back-channel multicasting is enabled by default, though you need to specify multicast addresses for it to work. You can use this method to multicast any media format that RealNetworks media players can play. Once you've set up multicasting, players attempt to connect in multicast mode first, using a unicast if the cannot connect to the multicast. This helps to save bandwidth by providing the most efficient possible connection for each player.

## Calculating Address Requirements

Determining the number of addresses you need for a back-channel multicast is straightforward. You need just one address per bit rate, regardless of the number of streams. So although a single-rate video technically delivers two streams, one for the audio track and one for the visuals, both tracks can use the same address.

### SureStream Broadcasts

For SureStream, you need to reserve one address for each bit rate encoded into the stream. If a SureStream stream is encoded for three audience bandwidth targets, for example, you need three addresses. The duress streams encoded for a particular bandwidth target are not used, and do not require additional addresses.

| Note: Media players cannot shift between SureStream streams during the multicast.

### Automatic Multicasts

If you intend to leave back-channel multicasting on for all broadcasts, you need enough multicast addresses to accommodate your typical broadcast. It's a good idea to implement a policy, such as using only two bandwidth targets when broadcasting RealVideo. If you have not reserved enough addresses for a particular multicast, the event is unicast automatically, as long as you have not disabled the failover feature.

## Configuring Back-Channel Multicasting

The following procedure describes how to set up Helix Universal Server for back-channel multicasting. Minimally, you need to define your multicast address range. Other features are optional.

| To set up back-channel multicasting:

1. In Helix Administrator, click Broadcast Distribution> Back-Channel Multicasting.

2. The Enable Multicast list turns on this feature. Ensure that the default value of `Yes` is selected. If you set this to `No`, multicasting is disabled, and all media players use unicasting for all broadcasts.

3. Set the Enable SAP list to `Yes` to announce the multicast session, as described in "Publicizing Your Multicasts".

4. In the PNA Port box, enter the port number on media clients where Helix Universal Server directs PNA multicast streams. The default is `7070`. PNA is used only with media clients earlier than RealPlayer G2, such as RealPlayer 5. These clients cannot play SureStream or SMIL.

5. In the RTSP Port box, list the port number on media clients where Helix Universal Server directs RTSP multicast streams. The default is `3554`.

6. Specify the range of addresses to which you want to multicast streams by filling in the IP Address Range box. Helix Universal Server uses the first available addresses in this range. See "Calculating Address Requirements" for information about the number of addresses you'll need.

7. Indicate how far multicast packets can travel over a network by typing a value in the Time to Live box. For more information, see "Packet Time to Live".

8. To allow missing packets to be resent to clients that request them, select `True` from the Resend list. Resending packets adds network overhead, but delivers higher-quality multicasts.

9. If you want to deliver the broadcast through multicasting alone, choose `Yes` from the Multicast Delivery Only list. Media players that cannot use multicasting will not be able to connect to the broadcast. Use this feature when broadcasting only to multicast-enabled media players, or if you are multicasting a high-bandwidth presentation and do not want to provide a unicast option.

| Warning! Selecting this option prevents you from unicasting any broadcast to RealNetworks media players. If you want to reuse unicasting after your multicast, turn this option off when the multicast ends.

10. The Access Rules section lets you restrict the range of media players that can connect to the multicast. A predefined rule allows all multicast-enabled players with access to the broadcast URL to connect to the multicast. You can delete this rule, modify it, and set up other rules as necessary:

1. To add a new rule, click the "+" icon and, optionally, change the default name in the Edit Client Access Rule Description box. Because the access rules simply list addresses of media players that have access, the order of the rules in the Access Rules box does not matter.

2. For the highlighted rule, enter an IP address or domain name for acceptable players in the Client IP Address or Hostname. The value `Any` is predefined for the first rule, meaning that all IP addresses are accepted. To restrict the range, delete the rule, or change its value and set a netmask.

3. In Client Netmask, specify the range of client IP addresses around the one you entered in the preceding step by selecting a bit mask. If Client IP Address is set to `Any`, though, leave Client Netmask set to `None`. See Appendix B for details about assigning a range of IP addresses using a bit mask.

11. Click Apply.

| Tip: General access control rules, which are described in Chapter 12, are enforced before multicast access rules. A media player excluded by general access control will not connect to any multicast, regardless of the multicast access rules.

## Starting a Back-Channel Multicast

After you configure a back-channel multicast, you start a unicast as described in Chapter 7. Media players that can connect to the multicast do so. Players that cannot connect to the multicast use a unicast, as long as the failover feature is not disabled. Links to both RTSP and PNA multicast are identical to links for unicasts. This enables a single link to serve both multicast and unicast clients. For information on linking formats, see "Linking to Unicasts".

# Setting Up Scalable Multicasting

This section describes how to set up a live channel to broadcast to any number of media players that support the RTP packet format and the scalable multicasting standards. This includes RealOne Player and Apple QuickTime Player. You can multicast any audio or video format that plays in the media players used by your audience.

| For More Information: The section "Multicast Resources" directs you to information about multicasting standards.

## Determining the Number of Addresses and Ports

You must reserve a contiguous block of IP addresses and a continuous range of Helix Universal Server ports for a scalable multicast. The number of addresses and ports you need is based on the number of streams you broadcast. The following sections describe how to calculate the numbers of addresses and ports you'll need.

| Note: The multicast addresses you choose cannot overlap with addresses assigned to back-channel multicasts.

### Single-Rate Audio and Video

A single-rate audio broadcast uses one stream, requiring one address. A single- rate video contains at least two streams, one for the audio track and one for the visual track. It may also have an event stream used to open URLs, for instance. The scalable multicasting specification requires an address for each stream. However, Helix Universal Server has a default Reuse Address feature that lets you use just one multicast IP address for each single-rate video, whether or not it includes an event stream. RealNetworks recommends that you use this feature unless you have a specific reason not to do so.

| Note: The Reuse Address feature works only with RealNetworks media players.

| Tip: Using multiple addresses is useful if media players use a low-bandwidth connection, and are able to play just the audio track of a video stream.

### SureStream RealAudio and RealVideo

For SureStream, you need to reserve one address for each encoded bit rate. If a SureStream RealAudio broadcast is encoded for three bandwidth targets, for example, you need three addresses. If you broadcast RealVideo and are not using the Reuse Address feature, you need two addresses for each rate. If a SureStream RealVideo broadcast is encoded for three audience bandwidth targets, for example, you need three addresses if the Reuse Address feature is used, six addresses if it isn't. The duress streams encoded for a particular bandwidth target are not used, and do not require additional addresses.

| Note: Media players cannot shift between SureStream streams during a multicast.

### Port Ranges

Scalable multicasts require a continuous, even-numbered range of ports. The number of ports required depends on the media type, and the number of bit rates encoded in the stream. You need to reserve two ports for each data stream:

- For video, reserve four ports for each encoded bit rate (two ports for each audio track, and two for each visual track) regardless of whether you use the Reuse Address feature. SureStream RealVideo with three encoded bit rates, for instance, needs 12 data ports.

- For audio, reserve two ports for each encoded bit rate. For SureStream RealAudio with three encoded bit rates, for example, you need 6 ports for data.

- An audio or video stream may also have an events stream, which requires an additional two ports. With RealAudio or RealVideo, for instance, an event stream can automatically open URLs in the viewer's Web browser.

| Tip: You can determine a clip or unicast stream's encoded bit rate (or rates) by playing the clip or live stream in RealOne Player, and giving the View>Clip>Clip Source command.

## Gathering Client Statistics

RealNetworks media players can transmit statistics about the amount and quality of data they received during a scalable multicast. As with unicasts, client statistics are sent at the end of a presentation (or when the player disconnects), and are stored in the access log described in Chapter 16. Once you have gathered statistics, you can draw conclusions about the quantity of clients and quality of service.

Because scalable multicasts can serve many thousands of players, your Helix Universal Server may not be able to handle all of the statistics connections at the end of the session, either because of load or client licensing limitations. In this case, you can limit the amount of information sent to Helix Universal Server (though not the number of connections), or offload the task to a Web server.

### Limiting Statistics

Under Logging & Monitoring>Access & Error Logging, you can control the type of data sent at the end of a scalable multicast by modifying the Client Stats setting. You can instruct clients to send minimal data by setting Logging Style to `0` and by clearing any Client Stats settings. The section "Logging Style" shows the data recorded with this logging style. Although it records minimal data, Helix Universal Server still accepts connections from all players, up to its licensed maximum.

| Note: If you change the access logging style, the setting applies to all content served through any method.

### Offloading Statistics to a Web Server

When players connect to a scalable multicast, Helix Universal Server can instruct them to send their connection statistics to a Web server at the end of the session. Web servers are often configured for load balancing, and may be better equipped than Helix Universal Server to handle large numbers of simultaneous connections that have short durations.

To use a Web server, you will need to write a CGI script that receives the statistics and to writes them to a log file. The statistics sent to the Web server are a subset of those normally recorded in the Helix Universal Server access log. They are transmitted through HTTP `POST`, and they use the following format, in which the `#` symbol is a separator:

    [Stat1:statistics_1][Stat2:statistics_2]#sent_time

| For More Information: See "Client Statistics" for details about client statistics 1 and 2.

## Setting Up a Live Channel

The following procedure explains how to set up a live channel for delivering a scalable multicast to RealNetworks media players. You might set up just one live channel for all scalable multicasts. Alternatively, you can create different live channels to multicast broadcast streams in different ways. To run two multicasts at the same time, for example, you define two separate channels.

| To create a live channel:

1. In Helix Administrator, click Broadcast Distribution>Scalable Multicasting.

2. The Mount Point box lists the mount point used for all scalable multicasts. The default mount point is /`scalable/`. RealNetworks recommends that you use this default value, but you may change it if you wish.

3. To create a new live channel, click the "+" icon and enter a descriptive name for this multicast session in the Edit Channel Description box.

4. Turn on scalable multicasting for this channel by selecting `Yes` from the Enable Channel list.

5. Set the Enable SAP list to `Yes` to announce the multicast session, as described in "Publicizing Your Multicasts".

6. In the Path box, identify the stream name the live broadcast uses. To accept all broadcast streams, keep the default value of an asterisk (`*`). Otherwise, specify a stream name, such as `live.rm`, and include any virtual path used by the encoder, as in `news/live.rm`. You do not need to include the encoder's unicast mount point, such as `/broadcast/` or `/encoder/`.

7. You next specify the ports and addresses used by the scalable multicast. Refer to "Determining the Number of Addresses and Ports" for more information on these topics.

1. In the Port Range boxes, type the port range where clients listen for streams.

2. In the IP Address Range boxes, type the range of addresses to use. Helix Universal Server uses the first available address in this range. To use a single address instead of a range, type the same address in each box.

| Tip: You can use the same range of ports and addresses for multiple channels. If you plan to multicast on multiple channels at the same time, however, ensure that your ranges are broad enough to cover all of the simultaneous multicasts. Although two channels can share the same range of addresses, for example, they cannot both broadcast on the same address simultaneously.

8. Indicate how far multicast packets can travel on your network in the Time to Live box. For information on these values, see "Packet Time to Live".

9. Type a value for Timeout. This represents the number of seconds a client waits for multicast packets before it stops, or uses the value in Alternate URL.

10. From the Reuse Address list, select `False` if you want to use a separate address for each stream in a video. Select `True` if you want to use one address for both streams. Refer to "Determining the Number of Addresses and Ports" for more information.

| Note: The Reuse Address feature works only with RealNetworks media players.

11. You next decide whether to shift media players that cannot receive the multicast to a unicast. This feature works only with RealNetworks media players.

1. From the Shift to Unicast list, select `No` if you do not want to shift clients to unicasting. You may want to choose this when broadcasting a high bit rate presentation in which a lot of unicast streams would consume too much bandwidth. If you choose `No`, you can ignore the next box.

2. To make the backup unicast available on the same Helix Universal Server, leave the Alternate Unicast URL box blank. If you want to shift unicasts to a different Helix Universal Server, supply that server's address and the path to the broadcast. Here is an example:

    rtsp://helixserver.example2.com/broadcast/vivaldi.rm

If you do not want to redirect players to an alternate stream, you can point them to a Web page that posts a message, such as, "This presentation is available only to multicast-enabled RealOne Players." In the Alternate Unicast URL box, enter the fully qualified URL of your Web page, such as the following:

    http://www.example.com/no_multicast.html

12. The next set of options controls whether client statistics are logged on Helix Universal Server, on a Web server, or not at all. For background on this feature, see "Gathering Client Statistics". Only RealNetworks clients report statistics, so you can set this to `No` if multicasting to other RTP-based media players.

1. In the Send Client Statistics to Web Server box, select `Yes` to have clients send their connection statistics to a Web server at the end of the multicast. Select `No` to send connection statistics to Helix Universal Server. If you select `No`, you can ignore the following settings.

2. In the Web Server Address or IP Address box, type the address of the Web server that collects the statistics.

3. In the Web Server Port box, type the HTTP port number of the Web server.

4. In the Web Server CGI Path box, type the path of the CGI script that consolidates the client statistics into a log file on the Web server. For example, enter:

    cgi-bin/client-stats/logstat

13. Click Apply.

## Delivering the Scalable Multicast

Once you've configured the multicast, you launch your broadcast as described in Chapter 7. If you leave scalable multicasting turned on, and configure your multicast to cover all broadcasts by entering "`*`" as the path, the multicast will be available for all unicasts intended for RealNetworks media players. Unlike back-channel multicasts, however, scalable multicasts use a different URL format than unicasts. This means that the scalable multicast is available only if you provide the proper multicast link.

| Tip: If you've enabled the Shift to Unicast feature, you can publish just the multicast URL for all broadcasts. Players that can connect through multicasting will do so. Players that cannot use multicasting will use unicasting.

### Multicast SDP Files

When Helix Universal Server receives a scalable multicast request, it automatically creates an SDP (Session Description Protocol) file, which is a standard format that contains information such as the multicast addresses and ports, as well as the broadcast stream's title, author, and copyright information.

The media player receives the SDP file when the viewer clicks the multicast link in a Web page, and connects to the multicast using the file's information. A viewer can also download the SDP file, typically by right-clicking on the Web page link, then connect to the multicast later by opening the file directly in the media player.

### Linking to a Scalable Multicast

Scalable multicast links differ from unicast links. They use the same format whether they appear in a Web page or in a metafile, and they always specify the HTTP protocol. The requested stream always ends with the `.sdp` extension. The following illustrates the link format:

    http://address:port/mount_point/path/file.rm.sdp

Here is an example in which Helix Universal Server uses its default port 80 for HTTP, so the port number is not listed:

    http://helixserver.example.com/scalable/news/live.rm.sdp

- The default mount point is `/scalable/`, but you can change this as described in "Setting Up a Live Channel". The `/ramgen/` parameter is not required, even though HTTP is used.

- A virtual path name such as `news/` is optional. You include it only if the encoder specifies this path when it delivers the stream.

- The requested file includes the stream name specified for the broadcast by the encoder, such as `live.rm`. You then append an extra `.sdp` extension. Even though MPEG unicasts link to an SDP file, as in `live_mp4.sdp`, the multicast requires an extra `.sdp` extension in the request URL, as in `live_mp4.sdp.sdp`.

| Tip: The SDP file contains exact channel settings. If you plan to repeat a multicast, and you want users to connect through a saved SDP file, use the same encoder settings, addresses, and ports as in the preceding multicast.

| Note: For players to receive the broadcast and log statistics, `/scalable` must be in the HTTP delivery list, which is described in "Allowing HTTP Delivery". Enabling scalable multicasts adds this mount point to the list automatically.

# Multicasting Windows Media

As with all Windows Media broadcasts, a Windows Media multicast is pulled from a Windows Media encoder the first time a Windows Media Player requests the multicast. You need only one IP address and port for each multicast. This style of multicasting builds on the basic unicasting definitions you set up according to instructions in "Broadcasting Windows Media".

## Defining a Multicast Channel

To set up Windows Media multicasts, you first define one or more multicast channels. A multicast can go out on a channel as long as the channel is enabled.

| To create a Windows Media multicast channel:

1. In Helix Administrator, click Broadcast Distribution>Windows Media Multicasting.

2. The NSCFilePath box lists the path to the NSC file, which Windows Media Players use to connect to multicasts. The default path is the `nscfile` directory under the `Content` directory, but you can change this to another directory that holds on-demand content. Helix Universal Server automatically generates the NSC file in the specified directory, using the channel name as the file name and `.nsc` as the extension.

| Note: If you use a different directory for the NSC file, add that path to the HTTP delivery list, as described in "Allowing HTTP Delivery".

3. To create a new live channel, click the "+" icon in the Channels section and enter a descriptive name for this multicast session in the Channel Name box. Because the channel name becomes the NSC file name, RealNetworks recommends that you do not include spaces or special characters in the name.

4. Enable multicasting for this channel by selecting `Yes` from the Enable Broadcast list. After the multicast, you can disable the channel by resetting this list to the default value `No`.

| Tip: Because Windows Media multicasts are pulled on request, and viewers can save the NSC file locally, it's a good idea to disable a channel when you do not intend to use it.

5. In the Multicast Address box, type the class D multicast address to use. You need only one address for each multicast. Each channel must use a different address.

6. In the Port Range boxes, type the port where clients should listen for streams on this channel. Each channel must use a different port.

7. Indicate how far multicast packets can travel on your network in the Time to Live box. For information on these values, see "Packet Time to Live".

8. In the Stream Description box, you can type any text that describes this multicast stream. This is for your reference, and is not used in the multicast.

9. To make a backup unicast available for media players that cannot join the multicast, supply the address and path to the unicast in the Alternate Unicast URL box. Although the unicast can be on the same Helix Universal Server, you need to define the address explicitly for the unicast failover to work. Here is an example:

    mms://helixserver.example.com/wmtencoder/chopin.wma

10. For Client Statistics URL, supply an HTTP address or host name for the Microsoft Internet Information Server (IIS) that gathers client statistics at the end of the multicast. If you leave this field blank, media players do not send back any statistics. Players cannot send statistics to Helix Universal Server.

| For More Information: Refer to the Windows Media Services documentation on reporting multicast statistics for instructions about setting up IIS to gather statistics.

11. Proceed to the next section if you want to define the live sources that use this multicast channel. You can click Apply to save the channel definition, however, if you want to set up its channel sources later.

## Setting Up a Live Source

Each channel can multicast a live stream from any number of Windows Media encoders. However, it can multicast a stream from just one of its live sources at a time. Below a channel definition, you set up the live sources that each channel can use. Each channel maintains a separate list of sources.

| To set up a live source for a channel:

1. In Helix Administrator, click Broadcast Distribution>Windows Media Multicasting.

2. In the Channels box at the top of the page, highlight the channel for which you want to create a live source.

3. Scroll to the bottom of the page and click the "+" icon in the Channel Sources section to set up a new live source.

4. Enter a descriptive name for this source in the Channel Source Name box. This name is for your reference only, and is not used in the multicast.

5. For Stream Format File, enter the full path and file name of the ASF file (extension `.asf`) that Windows Media Encoder generates and is copied to Helix Universal Server when the encoding begins. This file is used only by Helix Universal Server, and is not delivered to media players.

| Tip: Because ASF is a streaming format, RealNetworks recommends that you do not place the format file in a directory used for on-demand streaming. This helps you to avoid mistaking the format file for a streaming clip.

6. For Live Source, specify the mount point and stream name that identifies the live stream pulled from Windows Media Encoder. These elements are defined in the Windows Media unicast page, described in "Broadcasting Windows Media". The default mount point is `/wmtencoder/`, so a Live Source entry might look like this:

    /wmtencoder/live.wmv

| Warning! You must define a specific broadcast stream for each live source. Windows Media multicasting does not support the use of a wildcard character (such as "`*`") to pull all broadcasts that use the `/wmtencoder/` mount point.

7. Click Apply to save the live source definition.

## Running the Windows Media Multicast

Once you've enabled the multicast and defined the live source, you are ready to begin the multicast. Start Windows Media encoder running, and deliver the ASF stream format file to the predefined location on Helix Universal Server. The broadcast starts with the first media player request.

### Linking to the Multicast

Windows Media Players join the broadcast by requesting a download of the NSC file, which then instructs them on how to join the multicast. You can launch the broadcast through an HTTP link in a Web page, as shown in the following example. The `/asxgen/` mount point normally required to launch Windows Media Player is not required:

    http://helixserver.example.com/nscfile/live_channel.nsc

| Tip: If you're using the unicast failover option, you can publish just the NSC file URL. Players that can connect through multicasting will do so. Players that cannot use multicasting will switch to the unicast URL.

### Stopping a Windows Media Multicast

As a channel multicasts the stream, the channel name appears in the Transmitting Channels box at the top of the multicasting set-up page. To stop the broadcast, highlight the channel name, check the Stop Transmitting box, and click Apply. This changes the Enable Channel list to `No` to prevent the stream from being pulled again. To restart the channel, select `Yes` in the Enable Channel list and click Apply.

# Publicizing Your Multicasts

Optionally, you can publicize back-channel and scalable multicasts to anyone running a program that listens for the Session Announcement Protocol (SAP). These applications, such as SDR and ICAST Guide, display a list of all multicasts currently playing. Helix Universal Server creates the SAP file automatically. Programs that listen for SAP announcements show the title, author, and copyright information encoded into the files you multicast.

| Note: The Windows Media multicast format does not support Session Announcement Protocol.

| To set up Helix Universal Server to create SAP files:

1. In Helix Administrator, click Broadcast Distribution>Session Announcement.

2. In the Host IP Address box, type the IP address of this Helix Universal Server. The SAP announcement will include this address.

3. From the Enable SAP Service pull-down list, select `Yes`. This instructs Helix Universal Server to create and send SAP files. The default value is `No`.

4. From the Listen to SAP list, ensure that the default value of `Yes` is selected. This option enables Helix Universal Server to collect in-use multicast addresses. Helix Universal Server consults this list when selecting a multicast address from the user-supplied address range, thus ensuring that it selects unique addresses that are not in use elsewhere on your network.

5. Click Apply.

| © 2002 RealNetworks, Inc. All rights reserved. For more information, visit RealNetworks Click here if the Table of Contents frame is not visible at the left side of your screen.